❮

redacting password in SQL statement in server log

  • Jump to comment-1
    zyu@yugabyte.com2022-07-23T23:44:58+00:00
    Hi, Currently, in situation such as duplicate role creation, the server log would show something such as the following: 2022-07-22 13:48:18.251 UTC [330] STATEMENT: CREATE ROLE test WITH LOGIN PASSWORD 'foobar'; The password itself should be redacted before logging the statement. Here is sample output with the patch applied: 2022-07-23 23:28:20.359 UTC [16850] ERROR: role "test" already exists 2022-07-23 23:28:20.359 UTC [16850] STATEMENT: CREATE ROLE test WITH LOGIN PASSWORD Please take a look at the short patch. I know variables should be declared at the start of the func - I can do that once the approach is confirmed. Cheers
    • Jump to comment-1
      tgl@sss.pgh.pa.us2022-07-24T00:27:37+00:00
      Zhihong Yu <zyu@yugabyte.com> writes: > Currently, in situation such as duplicate role creation, the server log > would show something such as the following: > 2022-07-22 13:48:18.251 UTC [330] STATEMENT: CREATE ROLE test WITH LOGIN > PASSWORD 'foobar'; > The password itself should be redacted before logging the statement. This has been proposed multiple times, and rejected multiple times, primarily because it offers only false security: you'll never cover all the cases. (The proposed patch manages to create a bunch of false positives to go along with its false negatives, too.) The only safe answer is to be sure to keep the server log contents secure. Please see prior discussions in the archives. regards, tom lane
      • Jump to comment-1
        zyu@yugabyte.com2022-07-24T11:33:59+00:00
        On Sat, Jul 23, 2022 at 5:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Zhihong Yu <zyu@yugabyte.com> writes: > > Currently, in situation such as duplicate role creation, the server log > > would show something such as the following: > > > 2022-07-22 13:48:18.251 UTC [330] STATEMENT: CREATE ROLE test WITH LOGIN > > PASSWORD 'foobar'; > > > The password itself should be redacted before logging the statement. > > This has been proposed multiple times, and rejected multiple times, > primarily because it offers only false security: you'll never cover > all the cases. (The proposed patch manages to create a bunch of > false positives to go along with its false negatives, too.) > > The only safe answer is to be sure to keep the server log contents > secure. Please see prior discussions in the archives. > > regards, tom lane > Hi, I am thinking of adding `if not exists` to `CREATE ROLE` statement: CREATE ROLE trustworthy if not exists; In my previous example, if the user can issue the above command, there would be no SQL statement logged. Do you think it is worth adding `if not exists` clause ? Thanks
        • Jump to comment-1
          rjuju123@gmail.com2022-07-24T11:44:49+00:00
          Hi, On Sun, Jul 24, 2022 at 04:33:59AM -0700, Zhihong Yu wrote: > I am thinking of adding `if not exists` to `CREATE ROLE` statement: > > CREATE ROLE trustworthy if not exists; > > In my previous example, if the user can issue the above command, there > would be no SQL statement logged. It's not because there might not be an error that the password wouldn't end up in the logs (log_statement, log_min_duration_statement, typo in the command...). > > Do you think it is worth adding `if not exists` clause ? This has already been discussed and isn't wanted. You can refer to the last discussion about that at: https://www.postgresql.org/message-id/flat/CAOxo6XJy5_fUT4uDo2251Z_9whzu0JJGbtDgZKqZtOT9KhOKiQ@mail.gmail.com
      • Jump to comment-1
        zyu@yugabyte.com2022-07-24T01:27:59+00:00
        On Sat, Jul 23, 2022 at 5:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Zhihong Yu <zyu@yugabyte.com> writes: > > Currently, in situation such as duplicate role creation, the server log > > would show something such as the following: > > > 2022-07-22 13:48:18.251 UTC [330] STATEMENT: CREATE ROLE test WITH LOGIN > > PASSWORD 'foobar'; > > > The password itself should be redacted before logging the statement. > > This has been proposed multiple times, and rejected multiple times, > primarily because it offers only false security: you'll never cover > all the cases. (The proposed patch manages to create a bunch of > false positives to go along with its false negatives, too.) > > The only safe answer is to be sure to keep the server log contents > secure. Please see prior discussions in the archives. > > regards, tom lane > Pardon my laziness. I will pay more attention.